Systems and methods for amplifying the strength of cryptographic algorithms

ABSTRACT

Example embodiments provide systems and methods for increasing the cryptographic strength of an encryption or message-authentication-code- (MAC) generation technique. According to some embodiments, a MAC may be constructed around a shared secret (such as a random initialization number), thereby increasing strength of the MAC against brute force attacks based on the size of the shared secret. The MAC may be combined with randomized data, and may also be encrypted to further bolster the strength of the code. These elements (shared secret, MAC algorithm, and encryption algorithm) may be employed in various combinations and to varying degrees, depending on the application and desired level of security. At each stage, the cryptographic construct operates on the cyptographically modified data from the previous stage. This layering of cryptographic constructs may increase the strength of the group of contrasts more efficiently than applying any one construct with a larger key size or similar increase in complexity.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.16/458,961, filed on Jul. 1, 2019, which is a continuation-in-part ofU.S. patent application Ser. No. 16/205,119, filed on Nov. 29, 2018(issued as U.S. Pat. No. 10,581,611 on Mar. 3, 2020), which claimspriority from U.S. Provisional Application Ser. No. 62/740,352, filed onOct. 2, 2018. The contents of both aforementioned patent and patentapplications are incorporated herein by reference in their entireties.

FIELD OF THE INVENTION

The present disclosure relates to cryptography, and more particularly,to system and methods for cryptographic authentication of contactlesscards.

BACKGROUND

Data security and transaction integrity are of critical importance tobusinesses and consumers. This need continues to grow as electronictransactions constitute an increasingly large share of commercialactivity.

In some cases, it is important to authenticate the sender of a message(i.e., to verify that the message actually came from the user or deviceidentified as the originator of the message). It may also be importantto verify that the message has not been tampered with before receipt(i.e., that the information contained in the message remains the same aswhen it was transmitted).

Conventionally, a message authentication code (MAC) has been used forthis purpose. To generate a MAC, a sender uses a shared key inconjunction with a MAC algorithm to calculate a MAC value from themessage data. The sender then sends the message and the MAC value to areceiver, who is also in possession of the key. The receiver applies theMAC algorithm with the key to the received message to generate areceiver-side MAC. If the receiver-side MAC matches the MAC sent withthe message, the message is authenticated.

However, like any cryptographic technique, MACs are susceptible toattacks (including brute-force attacks). To measure its resistance toattack, a MAC may be associated with a strength, typically expressed interms of bits. For instance, a 100-bit effective strength indicates thatan attacker would need to perform 2¹⁰⁰ operations (1.27×10³⁰) in orderto guess the MAC using brute-force techniques. A 100-bit MAC would bestronger than an 80-bit MAC, for which the attacker would need toperform 2⁸⁰ operations (1.21×10²⁴).

Certain constraints relating to the required strength of a MAC or othercryptographic construct may be placed on data so that at least a minimumsecurity level (e.g., 100 bits) is required. These requirements may be aresult, for instance, of an organization's security procedures,regulatory requirements, or known security threats.

The strength of a MAC (or any cryptographic construct) is highlydependent on the cryptographic algorithm and cryptographic keys used toconstruct the MAC. In some cases, the size of the key or the type ofalgorithm used may be constrained by some element of the cryptographicsystem (e.g., security logic, processing capacity, memory usage,back-end hardware security modules, etc.).

A problem can therefore arise if a certain level of security (e.g., 100bits) is required, but due to constraints on the system only a lowerlevel of security (e.g., 60 bits) is readily achievable.

Similar problems arise in other cryptographic fields. For example, amessage may be encrypted before being transmitted on a network. Themessage may be encrypted using a given cryptographic algorithm thatrelies on a cryptographic key, where the strength of the encryption isdependent upon the size of the key. The cryptographic strength is againmeasured in terms of bits; for example, the well-known AdvancedEncryption Standard-128 (AES-128) uses a key size of 128 bits and isdesigned to offer 128 bits of cryptographic strength.

It should be noted, however, that the key size does not necessarilydirectly correlate to the cryptographic strength offered, because thestrength also depends on the algorithm being used. For instance, whenapplying the Triple Data Encryption Algorithm (Triple DES) with a168-bit key, an attack algorithm requiring 2¹¹² actions is known; thus,Triple DES offers only 112-bits of cryptographic strength despite usinga 168-bit key.

Sometimes, improved attacks are developed after an encryption standardis put into practice. As a result, an encryption protocol having acertain high level of security on one day may have a lower level ofsecurity the next.

In addition to cryptographic strength, there are several otherconsiderations when selecting an encryption algorithm and key size. Somealgorithms run more quickly than others, and in general increasing thekey size also increases the amount of time required to encrypt amessage. Thus, a system administrator needs to balance the securityoffered by an algorithm with the particular application (which mayrequire a certain speed or turnaround time).

Thus, problems can result when applying an encryption algorithm, where acertain level of security is required but, due to constraints on thesystem or data, that level of security may not be available orpractical.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A depicts an environment suitable for use with exemplaryembodiments.

FIG. 1B depicts an example of a contactless card having a physicaltoken.

FIG. 1C depicts the structure of an exemplary physical token.

FIG. 2A depicts an exemplary interface for a mobile applicationassociated with an owner of a contactless card.

FIG. 2B depicts an exemplary interface when the physical token is readby a reader on the owner's mobile device.

FIG. 2C depicts an example of data exchange between a contactless cardand a client device.

FIG. 2D depicts an exemplary data structure suitable for use withexemplary embodiments.

FIG. 3 is a flowchart illustrating key operations according to anexample embodiment.

FIG. 4 is a diagram of a key system according to an example embodiment.

FIG. 5 is a flowchart of a method of generating a cryptogram accordingto an example embodiment.

FIG. 6A is a flowchart illustrating a process of key diversificationaccording to an example embodiment.

FIG. 6B is a flowchart depicting block 606 of FIG. 6A in more detail.

FIG. 7 depicts an exemplary computing system suitable for use withexemplary embodiments.

FIG. 8 depicts an exemplary network environment suitable for use withexemplary embodiments.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

Exemplary embodiments provide techniques for constructing a strongcryptographic construct from multiple weak constructs, the combinationof a weak construct and a shared secret, or a combination of theconstructs and shared secrets. Using the techniques described herein,relatively weak constructs (i.e., constructs each individually offeringa cryptographic strength below a security requirement, referred toherein as S_(security_requirement)) may be combined to yield arelatively strong construct (i.e., a construct offering a cryptographicstrength above the security requirement).

According to exemplary embodiments, relatively weak cryptographicconstructs are layered to amplify their effective bit strength. In oneexample, a shared secret having an effective bit strength ofS_(shared_secret) may be provided, and a MAC algorithm having aneffective bit strength of S_(MAC_algorithm) may be applied to the sharedsecret. Although each of S_(shared_secret) and S_(MAC_algorithm) may beless than S_(security_requirement), combining these two elements asdescribed results in an effective bit strength ofS_(shared_secret)+S_(MAC_algorithm).

An important feature of exemplary embodiments is that the cryptographicoperations are layered to increase the resulting cryptographic strength,rather than applying such operations side-by-side (which does not resultin an increase in cryptographic strength). In other words, a firstcryptographic operation is applied to data to generate cryptographicallyencoded data, and then a second cryptographic operation is applied tothe cryptographically encoded data to generate further cryptographicallyencoded data. For example, a MAC may be applied to data to generate aMAC output, and then the MAC output may be further encrypted to amplifythe strength of the combined cryptographic operation. In effect, thelayering of the MAC output inside the encryption effectively amplifiesthe strength of the keys used for the individual cryptographicoperations.” If you prefer your original wording, then change “generatedMAC′ed data” to “generate MAC'ed data

This is in contrast to (e.g.) a system whereby data is encrypted and aMAC is generated from the encrypted data, and then the MAC and encrypteddata are both included in a message. Although the encryption and MACalgorithms both use cryptographic keys, the cryptographic operations areapplied independently and therefore this sequence does not magnify oramplify the cryptographic key strength.

As an illustrative example of layering to increase the effective keystrength, if the shared secret has a length of 32 bits, it would require2³² operations to exhaustively search the entire set of possible keyvalues. If the shared secret is then processed by a MAC algorithm havingan effective strength of 72 bits, then a potential brute-force attackerwould need to: (1) try every value for the 72-bit MAC key, and (2) foreach potential value of the MAC key, try each possible configuration ofthe 32-bit shared secret. Consequently, a brute-force attacker wouldneed to attempt 2³²*2⁷² possible values, resulting in a requirement for2¹⁰⁴ operations, or an effective bit strength of 104 bits.

Thus, it can be seen that if S_(security_requirement) is 100 and acryptographer only has access to a MAC algorithm having a 72-bitstrength and a shared secret of 32 bits, a cryptographic construct thatmeets the security requirement can be generated by applying the MACalgorithm to the shared secret. In this example, the layering occursbecause the shared secret is included inside the MAC operation

The strength of the construct can be further amplified by encrypting theresulting MAC. If the encryption algorithm used has an effective bitstrength of S_(encryption_algorithm), then the resulting construct'sstrength would correspond toS_(shared_secret)+S_(MAC_algorithm)+S_(encryption_algorithm). Thisprocess may be repeated and/or applied in various orderings orcombinations to yield a desired effective bit strength.

Multiple such examples are considered within the scope of the presentinvention. For instance, some contemplated embodiments involve:computing a MAC over a shared secret (alone or with other data);applying a MAC to message content and then encrypting the resulting MAC;applying a first MAC algorithm to message content or a shared secret(alone or with other data) and then applying a second MAC algorithm (thesame as or different than the first) to the resulting output; computinga MAC over a shared secret (alone or with other data) and encrypting theresult; and encrypting data with a first encryption algorithm/key toyield encrypted data, and then further encrypting the encrypted datausing a second encryption algorithm/key. In this latter embodiment, itis contemplated that different encryption algorithms could be combined,or the same encryption algorithm could be applied multiple times. Ineither case, the cryptographic algorithms should be used with differentencryption keys. It is not necessary that the effective bit strengths ofthe cryptographic constructs to be combined be the same.

As used herein, an encryption algorithm generally refers to an algorithmthat accepts an input and encodes the input to generate encryptedcontent that can be decrypted by an authorized party. A MAC algorithm,on the other hand, is not generally intended to be reversible (i.e.,when the MAC algorithm is applied to the input to generate a MAC output,the input typically cannot be reconstructed from the MAC output).Instead, the recipient either needs to be provided with a copy of theinput or needs to already be in possession of the input. The recipientcan run the same MAC algorithm using the same key on the input as wasapplied by the sender; if the MAC output generated by the recipient isthe same as the MAC output sent by the sender, the recipient knows thatthe input considered by the sender and the input considered by therecipient were the same (and that the message was not tampered with orcorrupted before receipt).

To further increase the security of exemplary embodiments, the keysapplied by the MAC and/or encrypted algorithms may be diversifiedsession keys that are computed based on a changing counter value knownto the sender and the receiver. In some embodiments, the cryptographicconstructs may be used to authenticate messages sent in association witha smart card, such as a credit card. A chip on the card may maintain acounter that increments each time the card is used, and a remotevalidation server may maintain a similar counter. The counter may beused to compute the MAC/encryption keys. Thus, even if a brute-forceattacker is able to reconstruct the key used to generate or protect aparticular message, the next message will be constructed with a new keybased on the new counter value. Accordingly, the key the attacker wasable to break was only good for one use; it cannot be used to attackfuture communications.

Exemplary embodiments are described below primarily in relation tocryptographic algorithms based on symmetric keys. Nonetheless, it isunderstood that this solution is not limited to these types ofalgorithms, and would apply to asymmetric algorithms as well.

As noted above, some embodiments may be used to protect messagestransmitted in connection with an authentication message for a smartcard having an embedded chip. An exemplary environment in which such anembodiment might be used is next described, before providing more detailon specific aspects of increasing the cryptographic strength of theauthentication message.

The following description of embodiments provides non-limitingrepresentative examples referencing numerals to particularly describefeatures and teachings of different aspects of the invention. Theembodiments described should be recognized as capable of implementationseparately, or in combination, with other embodiments from thedescription of the embodiments. The description of embodiments shouldfacilitate understanding of the invention to such an extent that otherimplementations, not specifically covered but within the knowledge of aperson of skill in the art having read the description of embodiments,would be understood to be consistent with an application of theinvention.

FIG. 1A illustrates a data transmission environment 100 according to anexample embodiment. As further discussed below, system 100 may includecontactless card including a physical token 106, a client device 104, anetwork 114, and a number of servers 116, 128. Although FIG. 1Aillustrates a particular configuration of components, one of ordinaryskill in the art will understand that other configurations includingmore or fewer components, or components in another configuration, may beused.

The environment 100 may include one or more contactless cards, which arefurther explained below with reference to FIG. 1B. In some examples, acontactless card may be in wireless communication, for example NFCcommunication, with the client device 104. The contactless card mayinclude a physical token 106, such as a contactless chip (see FIG. 1C).The physical token 106 may maintain a copy of the above-noted countervalue 108, which may be incremented each time the physical token is readby a reader (such as the NFC reader 110).

The environment 100 may include a client device 104, which may be anetwork-enabled computer. As referred to herein, a network-enabledcomputer may include, but is not limited to: e.g., a computer device, orcommunications device including, e.g., a server, a network appliance, apersonal computer (PC), a workstation, a mobile device, a phone, ahandheld PC, a personal digital assistant (PDA), a thin client, a fatclient, an Internet browser, or other device. The client device 104 alsomay be a mobile device; for example, a mobile device may include aniPhone, iPod, iPad from Apple® or any other mobile device runningApple's iOS operating system, any device running Microsoft's Windows®Mobile operating system, and/or any other smartphone or like wearablemobile device.

The client device 104 and/or the contactless card including the physicaltoken 106 may be associated with a user 102, which may be the owner ofthe contactless card. The user 102 may define credentials for accessinga mobile application on the client device 104, which may be anapplication associated with a service provider of the contactless card.

The client device 104 may include a near-field communications reader 110suitable for communicating with the physical token 106; for example, theNFC reader 100 may be used to read the counter value 108 from thephysical token 106.

In various examples according to the present disclosure, the clientdevice 104 of the environment 100 may execute one or more applications,such as software applications. The software applications may enablenetwork communications with one or more components of the environment100 and may transmit and/or receive data. Among othercomputer-executable logic, the client device 104 may include client-sidevalidation logic 112 (such as the logic depicted in more detail inconnection with FIG. 5).

The client device 104 may be in communication with one or more servers116, 128 via one or more networks 114, and may operate as a respectivefront-end to back-end pair with a transaction validation server 116. Theclient device 104 may transmit, for example from a mobile deviceapplication executing on client device 104, one or more requests to theserver 116. The one or more requests may be associated with retrievingdata from the server 116. The server 116 may receive the one or morerequests from client device 104. Based on the one or more requests fromthe client device 104, the server 116 may be configured to retrieve therequested data from one or more databases (not shown). Based on receiptof the requested data from the one or more databases, the server 116 maybe configured to transmit the received data to the client device 104,the received data being responsive to one or more requests.

The environment 100 may include one or more servers 116, 128. In someexamples, the servers 116, 128 may include one or more processors, whichare coupled to memory. The servers 116, 128 may be configured as acentral system, server or platform to control and call various data atdifferent times to execute a plurality of workflow actions. The servers116, 128 may be configured to connect to the one or more databases. Theclient device 104 may be connected to at least one of the servers 116,128.

In one embodiment, a third-party server 128 may request that atransaction be validated. For instance, the third-party server 128 maybe a server associated with a vendor selling a product or service, forwhich a purchase request is submitted in the name of the user 102. Thethird-party server 128 may request that the purchase be validated withthe service provider.

To that end, the third-party server 128 may communicate, via the network114, with a transaction validation server 116 affiliated with theservice provider. To validate the transaction, the server 116 mayexecute server-side validation logic 118 (such as the logic depicted inFIG. 6). The logic 118 may maintain a counter window 120 defining arange of acceptable counter values (which, as noted above, account foraccidental reads and other unintentional incrementing of the countervalue 108). The counter window 120 may include several different rangesassociated with different risk levels, such as a relatively wide rangefor low-risk transactions, and a relatively narrow range (which mayrequire an exact match) for high-risk transactions.

The logic 118 may apply the counter window 120 in conjunction with acounter value 126 stored in a user database 122 and indexed to a record124 associated with the user 102. For example, the counter window 120may be added to the stored counter value 126 to derive a maximumacceptable counter value, and the maximum acceptable counter value maybe compared to the counter value 108 received from the card. If thecard's counter value 108 does not exceed the maximum acceptable countervalue, a transaction may be authorized. If the card's counter value 108does exceed the maximum acceptable counter value, the user may be askedto reauthenticate the card (as described below), which provides theserver 116 with a new counter value 108 from the card. Assuming the newcounter value 108 from the card is consistent with the counter value 108previously received at the beginning of the transaction, the server 116may update its own stored counter value 126 to match the one provided bythe card. If not, further authentication steps may be required, or thetransaction may be denied.

The user database 122 need not necessarily be a database, but may be anydata structure suitable for storing a counter value 126 associated withthe physical token 106 of the user 102.

FIG. 1B illustrates one or more contactless cards 130, which maycomprise a payment card, such as a credit card, debit card, or giftcard, issued by a service provider 132 displayed on the front or back ofthe card 130. In some examples, the contactless card 130 is not relatedto a payment card, and may comprise, without limitation, anidentification card. In some examples, the payment card may comprise adual interface contactless payment card. The contactless card 130 maycomprise a substrate 134, which may include a single layer or one ormore laminated layers composed of plastics, metals, and other materials.Exemplary substrate materials include polyvinyl chloride, polyvinylchloride acetate, acrylonitrile butadiene styrene, polycarbonate,polyesters, anodized titanium, palladium, gold, carbon, paper, andbiodegradable materials. In some examples, the contactless card 130 mayhave physical characteristics compliant with the ID-1 format of theISO/IEC 7810 standard, and the contactless card may otherwise becompliant with the ISO/IEC 14443 standard. However, it is understoodthat the contactless card 130 according to the present disclosure mayhave different characteristics, and the present disclosure does notrequire a contactless card to be implemented in a payment card.

The contactless card 130 may also include identification information 136displayed on the front and/or back of the card, and a contact pad 138representing a physical token. The contact pad 138 may be configured toestablish contact with another communication device, such as a userdevice, smart phone, laptop, desktop, or tablet computer. Thecontactless card 130 may also include processing circuitry, antenna andother components not shown in FIG. 1C. These components may be locatedbehind the contact pad 138 or elsewhere on the substrate 134. Thecontactless card 130 may also include a magnetic strip or tape, whichmay be located on the back of the card (not shown in FIG. 1B).

As illustrated in FIG. 1C, the contact pad 138 of FIG. 1B may includeprocessing circuitry 140 for storing and processing information,including a microprocessor 142 and a memory 144. It is understood thatthe processing circuitry 140 may contain additional components,including processors, memories, error and parity/CRC checkers, dataencoders, anticollision algorithms, controllers, command decoders,security primitives and tamperproofing hardware, as necessary to performthe functions described herein.

The memory 144 may be a read-only memory, write-once read-multiplememory or read/write memory, e.g., RAM, ROM, and EEPROM, and thecontactless card 500 may include one or more of these memories. Aread-only memory may be factory programmable as read-only or one-timeprogrammable. One-time programmability provides the opportunity to writeonce then read many times. A write once/read-multiple memory may beprogrammed at a point in time after the memory chip has left thefactory. Once the memory is programmed, it may not be rewritten, but itmay be read many times. A read/write memory may be programmed andre-programed many times after leaving the factory. It may also be readmany times.

The memory 144 may be configured to store one or more applets 146, oneor more counters 108, and a customer identifier 148. The one or moreapplets 146 may comprise one or more software applications configured toexecute on one or more contactless cards, such as Java Card applet.However, it is understood that applets 146 are not limited to Java Cardapplets, and instead may be any software application operable oncontactless cards or other devices having limited memory. The one ormore counters 108 may comprise a numeric counter sufficient to store aninteger. The customer identifier 148 may comprise a unique alphanumericidentifier assigned to a user of the contactless card 130, and theidentifier may distinguish the user of the contactless card from othercontactless card users. In some examples, the customer identifier 148may identify both a customer and an account assigned to that customerand may further identify the contactless card associated with thecustomer's account.

The processor and memory elements of the foregoing exemplary embodimentsare described with reference to the contact pad, but the presentdisclosure is not limited thereto. It is understood that these elementsmay be implemented outside of the pad 138 or entirely separate from it,or as further elements in addition to processor 142 and memory 144elements located within the contact pad 138.

In some examples, the contactless card 130 may comprise one or moreantennas 150. The one or more antennas 150 may be placed within thecontactless card 130 and around the processing circuitry 140 of thecontact pad 138. For example, the one or more antennas 150 may beintegral with the processing circuitry 140 and the one or more antennas150 may be used with an external booster coil. As another example, theone or more antennas 150 may be external to the contact pad 138 and theprocessing circuitry 142.

In an embodiment, the coil of contactless card 130 may act as thesecondary of an air core transformer. The terminal may communicate withthe contactless card 130 by cutting power or amplitude modulation. Thecontactless card 130 may infer the data transmitted from the terminalusing the gaps in the contactless card's power connection, which may befunctionally maintained through one or more capacitors. The contactlesscard 130 may communicate back by switching a load on the contactlesscard's coil or load modulation. Load modulation may be detected in theterminal's coil through interference.

As explained above, the contactless cards 130 may be built on a softwareplatform operable on smart cards or other devices having limited memory,such as JavaCard, and one or more or more applications or applets may besecurely executed. Applets may be added to contactless cards to providea one-time password (OTP) for multifactor authentication (MFA) invarious mobile application-based use cases. Applets may be configured torespond to one or more requests, such as near field data exchange (NDEF)requests, from a reader, such as a mobile NFC reader, and produce anNDEF message that comprises a cryptographically secure OTP encoded as anNDEF text tag.

As noted above, exemplary transactions may validate a transactionrequested of an account associated with the contactless card via thelogic 112 executing on the client device 104. FIGS. 2A-2B depictexemplary interfaces that may be presented on the client device 104 inresponse to the logic.

Prior to displaying the interfaces, the user of the client 104 may benotified that a transaction requires validation. For instance, the usermay receive an SMS message from the service provider, may receive anotification through the service provider's application, may receive acall or an email, etc.

Upon receiving the notification, the user may log into the serviceprovider's application. The user may, for instance, supply a usernameand password, which may validate the user's identity. In otherembodiments, the user may be validated in other ways, such as throughbiometric data. In some embodiments, login may utilize two-factorauthentication (2FA).

When the user logs into the application, they may be presented with aninterface, such as the interface 200 depicted in FIG. 2A. In theinterface, a message 202 may be displayed indicating that a questionabletransaction has been received and requires validation. The message 202may include details of the transaction, such as the value of thetransaction, the name of the vendor attempting to validate thetransaction, etc.

The interface 200 may include an interactable element 204 allowing theuser to flag the transaction as fraudulent, if the user did notauthorize the transaction. Upon selecting the interactable element 204,the application may transmit a fraud alert message to the transactionvalidation server indicating that the transaction in question is notapproved.

The message 202 may also include instructions for validating thetransaction, if the user did authorize the transaction. In oneembodiment, validating the transaction may involve tapping the card 130to a reader on the back of the client device 104, as shown in FIG. 2B.The reader may read the counter value from the physical token on thecard 130, and may generate a message 300 (see FIG. 2D) including thecounter value 304 and an authentication cryptogram 306. The message 300may be encrypted.

The counter value 304 may correspond to the counter value most recentlyread from the card, and the authentication cryptogram 306 may begenerated based on cryptographic keys stored on the physical token 138and may be used to authenticate the card with the transaction validationserver and ensure that the message 300 has not been tampered with orcorrupted.

The message 300 may also include a token identifier 302, which mayidentify the card 130 and/or the user associated with the card. Forinstance, the token identifier 302 may correspond to the unique customeridentifier 148 stored in the physical token 138).

Upon receiving the message 300, the transaction validation server maydecrypt the message 300, validate the card and the message based on thecryptogram 306, match the message to a user account based on the tokenidentifier 302, and retrieve a user record 124 (see FIG. 1A) from thetransaction validation server corresponding to the user account. Thetransaction validation server may then compare the counter value 304 tothe corresponding counter value 126 stored in the user database 122 toverify that the number of reads or transactions on the card matches theexpected counter value stored on the server. This may validate that theuser is in possession of the card (i.e., that the message 300 is notforged) and that the number of transactions performed by the usermatches the service provider's expectation. If the counter values arenot in sync, this may indicate that unauthorized transactions have beenattempted and may result in the present transaction being declined (ormay result in additional validation actions being required).

One of ordinary skill in the art will understand that the message 300 isdepicted in a simplified format. In some embodiments, other componentsmay be present in the message, or the depicted components may becombined or modified.

FIG. 2C is a timing diagram illustrating an example sequence forproviding authenticated access according to one or more embodiments ofthe present disclosure. A system may include a contactless card 130 anda client device 104, which may include an application (which may includethe logic 112) and a processor.

At 202, the application communicates with the contactless card 130(e.g., after being brought near the contactless card 130). Communicationbetween the application and the contactless card 130 may involve thecontactless card 130 being sufficiently close to a card reader (notshown) of the client device 104 to enable NFC data transfer between theapplication and the contactless card 130.

At step 204, after communication has been established between clientdevice 104 and contactless card 130, the contactless card 130 generatesa message authentication code (MAC) cryptogram. In some examples, thismay occur when the contactless card 130 is read by an applicationhosting the logic 112. In particular, this may occur upon a read, suchas an NFC read, of a near field data exchange (NDEF) tag, which may becreated in accordance with the NFC Data Exchange Format. For example, areader, such as the logic 112, may transmit a message, such as an appletselect message, with the applet ID of an NDEF producing applet. Uponconfirmation of the selection, a sequence of select file messagesfollowed by read file messages may be transmitted. For example, thesequence may include “Select Capabilities file”, “Read Capabilitiesfile”, and “Select NDEF file”. At this point, a counter value maintainedby the contactless card 130 may be updated or incremented, which may befollowed by “Read NDEF file.” At this point, the message may begenerated which may include a header and a shared secret. Session keysmay then be generated. The MAC cryptogram may be created from themessage, which may include the header and the shared secret. The MACcryptogram may then be concatenated with one or more blocks of randomdata, and the MAC cryptogram and a random number (RND) may be encryptedwith the session key. Thereafter, the cryptogram and the header may beconcatenated, and encoded as ASCII hex and returned in NDEF messageformat (responsive to the “Read NDEF file” message).

In some examples, the MAC cryptogram may be transmitted as an NDEF tag,and in other examples the MAC cryptogram may be included with a uniformresource indicator (e.g., as a formatted string).

In some examples, the logic 112 may be configured to transmit a requestto the contactless card 130, the request comprising an instruction togenerate a MAC cryptogram.

At step 206, the contactless card 130 sends the MAC cryptogram to thelogic 112. In some examples, the transmission of the MAC cryptogramoccurs via NFC, however, the present disclosure is not limited thereto.In other examples, this communication may occur via Bluetooth, Wi-Fi, orother means of wireless data communication.

At step 208, the logic 112 communicates the MAC cryptogram to theprocessor.

At step 210, the processor verifies the MAC cryptogram pursuant to aninstruction from the logic 112. For example, the MAC cryptogram may beverified, as explained below.

In some examples, verifying the MAC cryptogram may be performed by adevice other than client device 104, such as a server 116 in datacommunication with the client device 104. For example, the processor mayoutput the MAC cryptogram for transmission to the server 116, which mayverify the MAC cryptogram.

In some examples, the MAC cryptogram may function as a digital signaturefor purposes of verification. Other digital signature algorithms, suchas public key asymmetric algorithms, e.g., the Digital SignatureAlgorithm and the RSA algorithm, or zero knowledge protocols, may beused to perform this verification.

FIG. 2D depicts an exemplary technique for generating a protectedmessage 230 in accordance with exemplary embodiments.

The message 230 may be configured to deliver information or content froma sender to a recipient. This information or content may be representedby message plaintext 234 (although the content may optionally beencrypted or otherwise protected).

The message plaintext 234 may be combined with a shared secret 232. Theshared secret 232 may be a random number known to both the sender andthe recipient. For instance, if the message plaintext 234 relates to anauthentication action for a contactless card as described above, theprocess of setting up or initializing the card may involve sharing arandom number between the chip on the card and the transactionvalidation server. In one embodiment, the random number may be a 32-bitrandom number. Alternatively or in addition, a communication session maybe set up by the sender and recipient; the process of setting up thecommunication session may involve sharing a random number between thesender and recipient, and the random number may be used as the sharedsecret 232.

The message plaintext 234 and the shared secret 232 may be combined invarious ways. In one embodiment, the message plaintext 234 may beencoded in a format so that it can be multiplied by the shared secret232. The resulting product may then be applied to the MAC algorithm. Inanother embodiment, the message plaintext 234 may be concatenated, inwhole or in part, with the shared secret 232. The resulting combinationmay then be applied to the MAC algorithm. The resulting MAC may beencrypted before transmission.

When the recipient (e.g. a receiving server) retrieves the MAC data, therecipient may decrypt the data to recover the MAC created by the sender.The recipient may then take the message plaintext 234 and combine itwith the agreed-upon shared secret 232 in the same way as was done atthe sender. The recipient may generate a MAC based on this combined dataand compare it to the MAC transmitted from the sender. If the two match,then the recipient can assume that the message has not been tamperedwith in transmission.

One of ordinary skill in the art will recognize that other techniquesexist for combining two different instances of data, any of which may besuitable for use with exemplary embodiments.

After the message plaintext 234 and the shared secret 232 are combined,they may be provided to a MAC algorithm 236. The MAC algorithm 236 maybe any suitable MAC algorithm, such as the data authentication algorithm(DAA), cipher block chaining message authentication codes (CBC-MAC),Galois message authentication code (GMAC), and hashed messageauthentication code (HMAC), among many others.

The MAC algorithm 236 operates using a key. In exemplary embodiments,this key may be a first diversified key 250 created using adiversification algorithm 248. The diversification algorithm may operateon the counter 108 received from the contactless card and a first masterkey 244 stored on the contactless card (described in more detail below)to generate the first diversified key 250. Using the first diversifiedkey 250 and the combined shared secret/plaintext, the MAC algorithm 236may generate MAC output 238.

The MAC output 238 may optionally be encrypted by an encryptionalgorithm 240 to generate an encrypted MAC 242. The encryption algorithm240 may be any suitable encryption algorithm, such as data encryptionstandard (DES), TripleDES (3DES), advanced encryption standard (AES),and RSA, among many others.

In some embodiments, the MAC output 238 may be combined with random data254. For instance, in one embodiment, the MAC output 238 may be combinedwith 8 bytes of randomly generated data 254. When the recipient receivesthe message 300, the recipient may decrypt the encrypted MAC 242 anddiscard the random data. The recipient may calculate its own version ofthe MAC, as described below, and may compare the recipient-generated MACto the data remaining from the encrypted MAC 242 received as part of themessage 230.

It should be clear to one practiced in the art that in some embodimentsthe MAC output 238 may be truncated such that only a portion of theoriginal MAC output is sent by the sender. The recipient will thenindependently compute the MAC output and similarly truncate it beforecomparing truncated MAC outputs

The encryption algorithm 240 also operates using a key. In exemplaryembodiments, this key may be a second diversified key 252 created usingthe diversification algorithm 248. The diversification algorithm mayoperate on the counter 108 received from the contactless card and asecond master key 246 stored on the contactless card (described in moredetail below) to generate the second diversified key 252. Using thesecond diversified key 252, the random data 254 and the MAC output 238are encrypted using the encryption algorithm 240 to create the encryptedMAC 242, which is included as a portion of the message 230.

The encrypted MAC 232 may be transmitted along with the messageplaintext 234. The counter value 108 may optionally be transmitted aspart of the message plaintext 234, and may be consulted by the recipient(e.g., the server) in authenticating the message. The shared secret 232is not directly sent as part of the message.

FIG. 3 is a flowchart illustrating key operations 300 according to anexample embodiment. As illustrated in FIG. 3, at block 310, two bankidentifier number (BIN) level master keys may be used in conjunctionwith the account identifier and card sequence number to produce twounique derived keys (UDKs) per card. In some examples, a bank identifiernumber may comprise one number or a combination of one or more numbers,such as an account number or an unpredictable number provided by one ormore servers, may be used for session key generation and/ordiversification. The UDKs (AUTKEY and ENCKEY) may be stored on the cardduring the personalization process.

At block 320, the counter may be used as the diversification data, sinceit changes with each use and provides a different session key each time,as opposed to the master key derivation in which one unique set of keysper card is produced. In some examples, it is preferable to use the4-byte method for both operations. Accordingly, at block 320, twosession keys may be created for each transaction from the UDKs, i.e.,one session key from AUTKEY and one session key from ENCKEY. In thecard, for the MAC key (i.e., the session key created from AUTKEY), thelow order of two bytes of the counter may be used for diversification.For the ENC key (i.e., the session key created from ENCKEY), the fulllength of the counter may be used for the ENC key.

At block 330, the MAC key may be used for preparing the MAC cryptogram,and the ENC key may be used to encrypt the cryptogram. For example, theMAC session key may be used to prepare the cryptogram, and the resultmay be encrypted with the ENC key before it is transmitted to the one ormore servers.

At block 340, verification and processing of the MAC is simplifiedbecause 2-byte diversification may be directly supported in the MACauthentication functions of payment HSMs. Decryption of the cryptogramis performed prior to verification of the MAC. The session keys areindependently derived at the one or more servers, resulting in a firstsession key (the ENC key) and a second session key (the MAC key). Thesecond derived key (i.e., the ENC key) may be used to decrypt the data,and the first derived key (i.e., the MAC key) may be used to verify thedecrypted data.

For the contactless card, a different unique identifier is derived whichmay be related to the application primary account number (PAN) and PANsequence number, which is encoded in the card. The key diversificationmay be configured to receive the identifier as input with the master keysuch that one or more keys may be created for each contactless card. Insome examples, these diversified keys may comprise a first key and asecond key. The first key may include an authentication master key (CardCryptogram Generation/Authentication Key—AUTKEY), and may be furtherdiversified to create a MAC session key used when generating andverifying a MAC cryptogram. The second key may comprise an encryptionmaster key (Card Data Encryption Key—ENCKEY), and may be furtherdiversified to create an ENC session key used when encrypting anddecrypting enciphered data. In some examples, the first and the secondkeys may be created by diversifying the issuer master keys by combiningthem with the card's unique ID number (pUID) and the PAN sequence number(PSN) of a payment applet. The pUID may comprise a 16-digit numericalvalue. As explained above, pUID may comprise a 16 digit BCD encodednumber. In some examples, pUID may comprise a 14-digit numerical value.

In some examples, the session key derivation method will use the low 2bytes of the counter. In these cases, the generated session key valueswill wrap after 2¹⁶ uses. In other examples it may be beneficial to use4 bytes of the counter in deriving the session key so that the key valuegenerated will not wrap until after 2³² uses. As will be obvious to onepracticed in the art, different numbers of bits or bytes from thecounter can be used as needed to generate session keys which will notwrap in the lifetime of the intended application.

In other examples, such as credit cards, a number, such as a transactionnumber or an unpredictable number provided by one or more servers, maybe used for session key generation and/or diversification.

FIG. 4 illustrates a diagram of a system 400 configured to implement oneor more embodiments of the present disclosure. As explained below,during the contactless card creation process, two cryptographic keys maybe assigned uniquely for each card. The cryptographic keys may comprisesymmetric keys which may be used to create session keys that are used inencryption and decryption of data, and to create a MAC. Triple DES(3DES) algorithm may be used by EMV and it is implemented by hardware inthe contactless card. By using a key diversification process, one ormore keys may be derived from a master key based upon uniquelyidentifiable information for each entity that requires a key.

Regarding master key management, two issuer master keys 405, 410 may berequired for each part of the portfolio on which the one or more appletsis issued. For example, the first master key 405 may comprise an IssuerCryptogram Generation/Authentication Key (Iss-Key-Auth) and the secondmaster key 410 may comprise an Issuer Data Encryption Key (Iss-Key-DEK).As further explained herein, two issuer master keys 405, 410 arediversified into card master keys 425, 430, which are unique for eachcard. In some examples, a network profile record ID (pNPR) 415 andderivation key index (pDKI) 420, as back office data, may be used toidentify which Issuer Master Keys 405, 410 to use in the cryptographicprocesses for authentication. The system performing the authenticationmay be configured to retrieve values of pNPR 415 and pDKI 420 for acontactless card at the time of authentication.

In some examples, to increase the security of the solution, a sessionkey may be derived (such as a unique key per session) but rather thanusing the card master keys 425, 530 to perform the MAC 436 andencryption 441 operations, the card master keys 425, 430 are used inconjunction with the counter 445 to derive session keys, as explainedabove. For example, each time the card is used in operation, a differentkey may be used for creating the message authentication code (MAC) andfor performing the encryption. Regarding session key generation, thekeys used to generate the cryptogram and encipher the data in the one ormore applets may comprise session keys based on the card unique keys(AUTKEY 425 and ENCKEY430). The session keys (MAC Key 435 and ENC Key440) may be generated by the one or more applets and derived by usingthe application transaction counter 445 with one or more algorithms. Tofit data into the one or more algorithms, only the 2 low order bytes ofthe 4-byte counter 445 is used. In some examples, the four byte sessionkey derivation method may comprise: F1:=counter(lower 2bytes)∥‘F0’∥‘00’∥PATC (four bytes) F1:=PATC(lower 2 bytes) ∥‘0F’∥‘00’∥counter(four bytes) SK:={(ALG (MK) [F1])∥ALG (MK) [F2]}, where ALG mayinclude 3DES ECB and MK may include the card unique derived master key.

As described herein, one or more MAC session keys may be derived usingthe lower two bytes of counter 445. At each tap of the contactless card,counter 445 is configured to be updated, and the card master keys AUTKEY425 and ENCKEY 430 are further diversified into the session keys MAC Key435 and ENC Key 440. Counter 445 may be initialized to zero atpersonalization or applet initialization time. In some examples, thecounter 445 may be initialized at or before personalization, and may beconfigured to increment by one at each NDEF read.

Further, the update for each card may be unique, and assigned either bypersonalization, or algorithmically assigned by pUID or otheridentifying information. For example, odd numbered cards may incrementor decrement by 2 and even numbered cards may increment or decrement by5. In some examples, the update may also vary in sequential reads, suchthat one card may increment in sequence by 1, 3, 5, 2, 2, . . .repeating. The specific sequence or algorithmic sequence may be definedat personalization time, or from one or more processes derived fromunique identifiers. This can make it harder for a replay attacker togeneralize from a small number of card instances.

The authentication message may be delivered as the content of a textNDEF record in hexadecimal ASCII format. In some examples, thecryptogram 460 will be the result of an encryption 441 which encrypts arandom block of data prepended to the output of the MAC operation 436.In some examples, the random number may precede cryptogram A and may beone block long. In other examples, there may be no restriction on thelength of the random number. In further examples, the total data (i.e.,the random number plus the cryptogram) may be a multiple of the blocksize. In these examples, an additional 8-byte block may be added tomatch the block produced by the MAC algorithm. As another example, ifthe algorithms employed used 16-byte blocks, even multiples of thatblock size may be used, or the output may be automatically, or manually,padded to a multiple of that block size.

The MAC may be performed by a function key (MAC Key) 435. The dataspecified in cryptogram may be processed with javacard.signature method:ALG_DES_MAC8_ISO9797_1_M2_ALG3 to correlate to EMV ARQC verificationmethods. The key used for this computation may comprise a session keyMAC Key 435, as explained above. As explained above, the low order twobytes of the counter may be used to diversify for the one or more MACsession keys. As explained below, MAC Key 435 may be used to MAC data450, and the resulting data or cryptogram A 455 and random number RNDmay be encrypted using ENC Key 440 to create cryptogram B or output 460sent in the message.

In some examples, one or more HSM commands may be processed fordecrypting such that the final 16 (binary, 32 hex) bytes may comprise a3DES symmetric encrypting using CBC mode with a zero IV of the randomnumber followed by MAC authentication data. The key used for thisencryption may comprise a session key ENC Key 440 derived from theENCKEY 430. In this case, the derivation data for the session keyderivation is the least significant two bytes of the counter 445.

The format below represents a binary version example embodiment.Further, in some examples, the first byte may be set to ASCII ‘A’.

Another exemplary format is shown below. In this example, the tag may beencoded in hexadecimal format.

The UID field of the received message may be extracted to derive, frommaster keys Iss-Key-AUTH 405 and Iss-Key-DEK 410, the card master keys(AUTKEY 425 and ENCKEY 430) for that particular card. Using the cardmaster keys (AUTKEY 425 and ENCKEY 430), the counter field of thereceived message may be used to derive the session keys (MAC Key 435 andENC Key 440) for that particular card. Cryptogram B 460 may be decryptedusing the ENC Key 440, which yields cryptogram A 455 and RND, and RNDmay be discarded. The UID field may be used to look up the shared secretof the contactless card which, along with the Ver, UID, and counterfields of the message, may be processed through the cryptographic MACusing the re-created MAC Key 435 to create a MAC output, such as MAC′.If MAC′ is the same as cryptogram A 955, then this indicates that themessage decryption and MAC checking have all passed. Then the countermay be read to determine if it is valid.

During an authentication session, one or more cryptograms may begenerated by the one or more applications. For example, the one or morecryptograms may be generated as a 3DES MAC using ISO 9797-1 Algorithm 3with Method 2 padding via one or more session keys, such as MAC Key 435.The input data 450 may take the following form: Version (2), pUID (8),pATC (4), Shared Secret (4). In some examples, the numbers in thebrackets may comprise length in bytes. In some examples, the sharedsecret may be generated by one or more random number generators whichmay be configured to ensure, through one or more secure processes, thatthe random number is unpredictable. In some examples, the shared secretmay comprise a random 4-byte binary number injected into the card atpersonalization time that is known by the authentication service. Duringan authentication session, the shared secret may not be provided fromthe one or more applets to the mobile application. Method 2 padding mayinclude adding a mandatory 0x‘80’ byte to the end of input data and0x‘00’ bytes that may be added to the end of the resulting data up tothe 8-byte boundary. The resulting cryptogram may comprise 8 bytes inlength.

In some examples, one benefit of encrypting an unshared random number asthe first block with the MAC cryptogram, is that it acts as aninitialization vector while using CBC (Block chaining) mode of thesymmetric encryption algorithm. This allows the “scrambling” from blockto block without having to pre-establish either a fixed or dynamic IV.

By including the application transaction counter 445 as part of the dataincluded in the MAC cryptogram, the authentication service may beconfigured to determine if the value conveyed in the clear data has beentampered with. Moreover, by including the version in the one or morecryptograms, it is difficult for an attacker to purposefullymisrepresent the application version in an attempt to downgrade thestrength of the cryptographic solution. In some examples, the counter445 may start at zero and be updated by 1 each time the one or moreapplications generates authentication data. The authentication servicemay be configured to track the counters 445 used during authenticationsessions. In some examples, when the authentication data uses a counter445 equal to or lower than the previous value received by theauthentication service, this may be interpreted as an attempt to replayan old message, and the authenticated may be rejected. In some examples,where the counter 445 is greater than the previous value received, thismay be evaluated to determine if it is within an acceptable range orthreshold, and if it exceeds or is outside the range or threshold,verification may be deemed to have failed or be unreliable. In the MACoperation 436, data 450 is processed through the MAC using MAC Key 435to produce MAC output (cryptogram A) 455, which is encrypted.

In order to provide additional protection against brute force attacksexposing the keys on the card, it is desirable that the MAC cryptogram455 be enciphered. In some examples, data or cryptogram A 455 to beincluded in the ciphertext may comprise: Random number (8), cryptogram(8). In some examples, the numbers in the brackets may comprise lengthin bytes. In some examples, the random number may be generated by one ormore random number generators which may be configured to ensure, throughone or more secure processes, that the random number is unpredictable.The key used to encipher this data may comprise a session key. Forexample, the session key may comprise ENC Key 440. In the encryptionoperation 441, data or cryptogram A 455 and RND are processed using ENCKey 440 to produce encrypted data, cryptogram B 460. The data 455 may beenciphered using 3DES in cipher block chaining mode to ensure that anattacker must run any attacks over all of the ciphertext. As anon-limiting example, other algorithms, such as Advanced EncryptionStandard (AES), may be used. In some examples, an initialization vectorof 0x‘0000000000000000’ may be used. Any attacker seeking to brute forcethe key used for enciphering this data will be unable to determine whenthe correct key has been used, as correctly decrypted data will beindistinguishable from incorrectly decrypted data due to its randomappearance.

In order for the authentication service to validate the one or morecryptograms provided by the one or more applets, the following data mustbe conveyed from the one or more applets to the mobile device in theclear during an authentication session: version number to determine thecryptographic approach used and message format for validation of thecryptogram, which enables the approach to change in the future; pUID toretrieve cryptographic assets, and derive the card keys; and counter 445to derive the session key used for the cryptogram.

FIG. 5 illustrates a method 500 for generating a cryptogram. Forexample, at block 510, a network profile record ID (pNPR) and derivationkey index (pDKI) may be used to identify which Issuer Master Keys to usein the cryptographic processes for authentication. In some examples, themethod may include performing the authentication to retrieve values ofpNPR and pDKI for a contactless card at the time of authentication.

At block 520, Issuer Master Keys may be diversified by combining themwith the card's unique ID number (pUID) and the PAN sequence number(PSN) of one or more applets, for example, a payment applet.

At block 530, AUTKEY 425 and ENCKEY 430 (unique card keys) may becreated by diversifying the Issuer Master Keys to generate session keyswhich may be used to generate a MAC cryptogram.

At block 540, the keys used to generate the cryptogram and encipher thedata in the one or more applets may comprise the session keys of block530 based on the card unique keys (AUTKEY 425 and ENCKEY 430). In someexamples, these session keys may be generated by the one or more appletsand derived by using counter 445, resulting in session keys MAC Key 435and ENC Key 440.

FIG. 6 depicts an exemplary process 600 illustrating key diversificationaccording to one example. Initially, a sender and the recipient may beprovisioned with two different master keys. For example, a first masterkey may comprise the data encryption master key, and a second master keymay comprise the data integrity master key. The sender has a countervalue, which may be updated at block 602, and other data, such as datato be protected, which it may securely share with the recipient.

At block 604, the counter value may be encrypted by the sender using thedata encryption master key to produce the data encryption derivedsession key, and the counter value may also be encrypted by the senderusing the data integrity master key to produce the data integrityderived session key. In some examples, a whole counter value or aportion of the counter value may be used during both encryptions.

In some examples, the counter value may not be encrypted. In theseexamples, the counter may be transmitted between the sender and therecipient in the clear, i.e., without encryption.

At block 606, the data to be protected is processed with a cryptographicMAC operation by the sender using the data integrity session key and acryptographic MAC algorithm. The protected data, including plaintext andshared secret, may be used to produce a MAC using one of the sessionkeys (MAC Key 435).

Block 606 is described in more detail in connection with FIG. 6B. Theactions described in connection with FIG. 6B may be performed by theprocessor 142 on the contact pad 138 of the contactless card 130.

As shown in FIG. 6B, at block 618 the system may access the protecteddata, which is used to generate the MAC.

If the protected data is to be combined with a shared secret, then atblock 620 the system may optionally access the shared secret (e.g., arandom number generated when the contactless card was first initialized,or when a communication session associated with the card wasestablished, and shared between the server and the contactless card). Atblock 622, the system may combine the shared secret and the protecteddata, such as by appending the shared secret to the protected data(among other possibilities, such as applying a logical or Booleanoperation to the shared secret and protected data).

At block 624, the system may apply a MAC algorithm to the combined data.The MAC algorithm relies on a key in order to generate a MAC, which maybe a diversified session key generated using a counter value asdescribed above.

At block 626, the system may determine if the MAC algorithm (optionallyapplied in conjunction with the shared secret) is sufficiently secure tomeet a security requirement of the system. For instance, the system maybe provided with a minimum security rating (e.g., expressed in bits),and may determine if the actions taken at blocks 622-624 were sufficientto meet the security rating. In making this determination, the systemmay add the size of the shared secret (if used) to the security ratingof the MAC algorithm (which may be defined by the size of thediversified session key). If the result is greater than the minimumsecurity requirement, then processing may proceed to block 610 and theMAC may be transmitted.

If the result is not greater than the minimum security requirement (“NO”at block 626), then processing may proceed to block 628 and the systemmay apply an encryption algorithm to the already MAC′ed data using thesecond diversified session key as described above. Processing may thenreturn to block 626, where the resulting construct is reevaluated todetermine if the construct meets the minimum security rating. If so,processing proceeds to block 610 and the (now encrypted) MAC istransmitted. If not, processing may return to block 628 and the systemmay apply further encryption to the encrypted data to further increasethe security of the encrypted data. The system may apply the sameencryption algorithm as was previously applied, or may apply a differentencryption algorithm. The system may use a different key (e.g., a thirddiversified session key generated based on a third master key or otherdata known to both the card and the server). Block 628 may be repeateduntil a sufficient security rating is reached.

FIG. 6B depicts but one exemplary technique for increasing the securityof a cryptographic structure (in this case, a MAC). However, one ofordinary skill in the art will recognize that the depicted blocks may beperformed in a different order without diverging from the spirit of theinvention. Moreover, some blocks may be eliminated, some blocks may beadded, and some depicted blocks may be performed more than once toincrease the cryptographic strength of the construct.

It will further be evident that, although exemplary embodiments aredescribed in connection with authenticating messages pertaining tocontactless cards, the present invention is not so limited. The conceptsdescribed herein, including the augmenting of cryptographic strength fora MAC or encryption algorithm, may be applied in any cryptographiccontext.

Returning to FIG. 6A, at block 608 the data to be protected may beencrypted by the sender using the data encryption derived session key inconjunction with a symmetric encryption algorithm. In some examples, theMAC is combined with an equal amount of random data, for example each 8bytes long, and then encrypted using the second session key(DEK-Session-Key).

At block 610, the encrypted MAC is transmitted, from the sender to therecipient, with sufficient information to identify additional secretinformation (such as shared secret, master keys, etc.), for verificationof the cryptogram.

At block 612, the recipient uses the received counter value toindependently derive the two derived session keys from the two masterkeys as explained above.

At block 614, the data encryption derived session key is used inconjunction with the symmetric decryption operation to decrypt theprotected data. Additional processing on the exchanged data will thenoccur. In some examples, after the MAC is extracted, it is desirable toreproduce and match the MAC. For example, when verifying the cryptogram,it may be decrypted using appropriately generated session keys. Theprotected data may be reconstructed for verification. A MAC operationmay be performed using an appropriately generated session key todetermine if it matches the decrypted MAC. As the MAC operation is anirreversible process, the only way to verify is to attempt to recreateit from source data.

At block 616, the data integrity derived session key is used inconjunction with the cryptographic MAC operation to verify that theprotected data has not been modified.

Some examples of the methods described herein may advantageously confirmwhen a successful authentication is determined when the followingconditions are met. First, the ability to verify the MAC shows that thederived session key was proper. The MAC may only be correct if thedecryption was successful and yielded the proper MAC value. Thesuccessful decryption may show that the correctly derived encryption keywas used to decrypt the encrypted MAC. Since the derived session keysare created using the master keys known only to the sender (e.g., thetransmitting device) and recipient (e.g., the receiving device), it maybe trusted that the contactless card which originally created the MACand encrypted the MAC is indeed authentic. Moreover, the counter valueused to derive the first and second session keys may be shown to bevalid and may be used to perform authentication operations.

Thereafter, the two derived session keys may be discarded, and the nextiteration of data exchange will update the counter value (returning toblock 602) and a new set of session keys may be created (at block 604).In some examples, the combined random data may be discarded.

Example embodiments of systems and methods described herein may beconfigured to provide security factor authentication. The securityfactor authentication may comprise a plurality of processes. As part ofthe security factor authentication, a first process may comprise loggingin and validating a user via one or more applications executing on adevice. As a second process, the user may, responsive to successfullogin and validation of the first process via the one or moreapplications, engage in one or more behaviors associated with one ormore contactless cards. In effect, the security factor authenticationmay include both securely proving identity of the user and engaging inone or more types of behaviors, including but not limited to one or moretap gestures, associated with the contactless card. In some examples,the one or more tap gestures may comprise a tap of the contactless cardby the user to a device. In some examples, the device may comprise amobile device, a kiosk, a terminal, a tablet, or any other deviceconfigured to process a received tap gesture.

In some examples, the contactless card may be tapped to a device, suchas one or more computer kiosks or terminals, to verify identity so as toreceive a transactional item responsive to a purchase, such as a coffee.By using the contactless card, a secure method of proving identity in aloyalty program may be established. Securely proving the identity, forexample, to obtain a reward, coupon, offer, or the like or receipt of abenefit is established in a manner that is different than merelyscanning a bar card. For example, an encrypted transaction may occurbetween the contactless card and the device, which may configured toprocess one or more tap gestures. As explained above, the one or moreapplications may be configured to validate identity of the user and thencause the user to act or respond to it, for example, via one or more tapgestures. In some examples, data for example, bonus points, loyaltypoints, reward points, healthcare information, etc., may be written backto the contactless card.

In some examples, the contactless card may be tapped to a device, suchas a mobile device. As explained above, identity of the user may beverified by the one or more applications which would then grant the usera desired benefit based on verification of the identity.

In some examples, the contactless card may be activated by tapping to adevice, such as a mobile device. For example, the contactless card maycommunicate with an application of the device via a card reader of thedevice through NFC communication. The communication, in which a tap ofthe card proximate the card reader of the device may allow theapplication of the device to read data associated with the contactlesscard and activate the card. In some examples, the activation mayauthorize the card to be used to perform other functions, e.g.,purchases, access account or restricted information, or other functions.In some examples, the tap may activate or launch the application of thedevice and then initiate one or more actions or communications with oneor more servers to activate the contactless card. If the application isnot installed on the device, a tap of the contactless card proximate thecard reader may initiate a download of the application, such asnavigation to a download page of the application). Subsequent toinstallation, a tap of the contactless card may activate or launch theapplication, and then initiate, for example via the application or otherback-end communication), activation of the contactless card. Afteractivation, the contactless card may be used in various activities,including without limitation commercial transactions.

In some embodiments, a dedicated application may be configured toexecute on a client device to perform the activation of the contactlesscard. In other embodiments, a webportal, a web-based app, an applet,and/or the like may perform the activation. Activation may be performedon the client device, or the client device may merely act as a gobetween for the contactless card and an external device (e.g., accountserver). According to some embodiments, in providing activation, theapplication may indicate, to the account server, the type of deviceperforming the activation (e.g., personal computer, smartphone, tablet,or point-of-sale (POS) device). Further, the application may output, fortransmission, different and/or additional data to the account serverdepending on the type of device involved. For example, such data maycomprise information associated with a merchant, such as merchant type,merchant ID, and information associated with the device type itself,such as POS data and POS ID.

In some embodiments, the example authentication communication protocolmay mimic an offline dynamic data authentication protocol of the EMVstandard that is commonly performed between a transaction card and apoint-of-sale device, with some modifications. For example, because theexample authentication protocol is not used to complete a paymenttransaction with a card issuer/payment processor per se, some datavalues are not needed, and authentication may be performed withoutinvolving real-time online connectivity to the card issuer/paymentprocessor. As is known in the art, point of sale (POS) systems submittransactions including a transaction value to a card issuer. Whether theissuer approves or denies the transaction may be based on if the cardissuer recognizes the transaction value. Meanwhile, in certainembodiments of the present disclosure, transactions originating from amobile device lack the transaction value associated with the POSsystems. Therefore, in some embodiments, a dummy transaction value(i.e., a value recognizable to the card issuer and sufficient to allowactivation to occur) may be passed as part of the example authenticationcommunication protocol. POS based transactions may also declinetransactions based on the number of transaction attempts (e.g.,transaction counter). A number of attempts beyond a buffer value mayresult in a soft decline; the soft decline requiring furtherverification before accepting the transaction. In some implementations,a buffer value for the transaction counter may be modified to avoiddeclining legitimate transactions.

In some examples, the contactless card can selectively communicateinformation depending upon the recipient device. Once tapped, thecontactless card can recognize the device to which the tap is directed,and based on this recognition the contactless card can provideappropriate data for that device. This advantageously allows thecontactless card to transmit only the information required to completethe instant action or transaction, such as a payment or cardauthentication. By limiting the transmission of data and avoiding thetransmission of unnecessary data, both efficiency and data security canbe improved. The recognition and selective communication of informationcan be applied to a various scenarios, including card activation,balance transfers, account access attempts, commercial transactions, andstep-up fraud reduction.

If the contactless card tap is directed to a device running Apple's iOS®operating system, e.g., an iPhone, iPod, or iPad, the contactless cardcan recognize the iOS® operating system and transmit data appropriatedata to communicate with this device. For example, the contactless cardcan provide the encrypted identity information necessary to authenticatethe card using NDEF tags via, e.g., NFC. Similarly, if the contactlesscard tap is directed to a device running the Android® operating system,e.g., an Android® smartphone or tablet, the contactless card canrecognize the Android® operating system and transmit appropriate anddata to communicate with this device (such as the encrypted identityinformation necessary for authentication by the methods describedherein).

As another example, the contactless card tap can be directed to a POSdevice, including without limitation a kiosk, a checkout register, apayment station, or other terminal. Upon performance of the tap, thecontactless card can recognize the POS device and transmit only theinformation necessary for the action or transaction. For example, uponrecognition of a POS device used to complete a commercial transaction,the contactless card can communicate payment information necessary tocomplete the transaction under the EMV standard.

In some examples, the POS devices participating in the transaction canrequire or specify additional information, e.g., device-specificinformation, location-specific information, and transaction-specificinformation, that is to be provided by the contactless card. Forexample, once the POS device receives a data communication from thecontactless card, the POS device can recognize the contactless card andrequest the additional information necessary to complete an action ortransaction.

In some examples the POS device can be affiliated with an authorizedmerchant or other entity familiar with certain contactless cards oraccustomed to performing certain contactless card transactions. However,it is understood such an affiliation is not required for the performanceof the described methods.

In some examples, such as a shopping store, grocery store, conveniencestore, or the like, the contactless card may be tapped to a mobiledevice without having to open an application, to indicate a desire orintent to utilize one or more of reward points, loyalty points, coupons,offers, or the like to cover one or more purchases. Thus, an intentionbehind the purchase is provided.

In some examples, the one or more applications may be configured todetermine that it was launched via one or more tap gestures of thecontactless card, such that a launch occurred at 3:51 pm, that atransaction was processed or took place at 3:56 pm, in order to verifyidentity of the user.

In some examples, the one or more applications may be configured tocontrol one or more actions responsive to the one or more tap gestures.For example, the one or more actions may comprise collecting rewards,collecting points, determine the most important purchase, determine theleast costly purchase, and/or reconfigure, in real-time, to anotheraction.

In some examples, data may be collected on tap behaviors asbiometric/gestural authentication. For example, a unique identifier thatis cryptographically secure and not susceptible to interception may betransmitted to one or more backend services. The unique identifier maybe configured to look up secondary information about individual. Thesecondary information may comprise personally identifiable informationabout the user. In some examples, the secondary information may bestored within the contactless card.

In some examples, the device may comprise an application that splitsbills or check for payment amongst a plurality of individuals. Forexample, each individual may possess a contactless card, and may becustomers of the same issuing financial institution, but it is notnecessary. Each of these individuals may receive a push notification ontheir device, via the application, to split the purchase. Rather thanaccepting only one card tap to indicate payment, other contactless cardsmay be used. In some examples, individuals who have different financialinstitutions may possess contactless cards to provide information toinitiate one or more payment requests from the card-tapping individual.

The following example use cases describe examples of particularimplementations of the present disclosure. These are intended solely forexplanatory purposes and not for purposes of limitation. In one case, afirst friend (payor) owes a second friend (payee) a sum of money. Ratherthan going to an ATM or requiring exchange through a peer-to-peerapplication, payor wishes to pay via payee's smartphone (or otherdevice) using a contactless card. Payee logs-on to the appropriateapplication on his smartphone and selects a payment request option. Inresponse, the application requests authentication via payee'scontactless card. For example, the application outputs a displayrequesting that payee tap his contactless card. Once payee taps hiscontactless card against the screen of his smartphone with theapplication enabled, the contactless card is read and verified. Next,the application displays a prompt for payor to tap his contactless cardto send payment. After the payor taps his contactless card, theapplication reads the card information and transmits, via an associatedprocessor, a request for payment to payor's card issuer. The card issuerprocesses the transaction and sends a status indicator of thetransaction to the smartphone. The application then outputs for displaythe status indicator of the transaction.

In another example case, a credit card customer may receive a new creditcard (or debit card, other payment card, or any other card requiringactivation) in the mail. Rather than activating the card by calling aprovided telephone number associated with the card issuer or visiting awebsite, the customer may decide to activate the card via an applicationon his or her device (e.g., a mobile device such as a smartphone). Thecustomer may select the card activation feature from the application'smenu that is displayed on a display of the device. The application mayprompt the customer to tap his or her credit card against the screen.Upon tapping the credit card against the screen of the device, theapplication may be configured to communicate with a server, such as acard issuer server which activates the customer's card. The applicationmay then display a message indicating successful activation of the card.The card activation would then be complete.

The above-described methods may be embodied as instructions on acomputer readable medium or as part of a computing architecture. FIG. 7illustrates an embodiment of an exemplary computing architecture 700suitable for implementing various embodiments as previously described.In one embodiment, the computing architecture 700 may comprise or beimplemented as part of an electronic device, such as a computer 701. Theembodiments are not limited in this context.

As used in this application, the terms “system” and “component” areintended to refer to a computer-related entity, either hardware, acombination of hardware and software, software, or software inexecution, examples of which are provided by the exemplary computingarchitecture 700. For example, a component can be, but is not limited tobeing, a process running on a processor, a processor, a hard disk drive,multiple storage drives (of optical and/or magnetic storage medium), anobject, an executable, a thread of execution, a program, and/or acomputer. By way of illustration, both an application running on aserver and the server can be a component. One or more components canreside within a process and/or thread of execution, and a component canbe localized on one computer and/or distributed between two or morecomputers. Further, components may be communicatively coupled to eachother by various types of communications media to coordinate operations.The coordination may involve the uni-directional or bi-directionalexchange of information. For instance, the components may communicateinformation in the form of signals communicated over the communicationsmedia. The information can be implemented as signals allocated tovarious signal lines. In such allocations, each message is a signal.Further embodiments, however, may alternatively employ data messages.Such data messages may be sent across various connections. Exemplaryconnections include parallel interfaces, serial interfaces, and businterfaces.

The computing architecture 700 includes various common computingelements, such as one or more processors, multi-core processors,co-processors, memory units, chipsets, controllers, peripherals,interfaces, oscillators, timing devices, video cards, audio cards,multimedia input/output (I/O) components, power supplies, and so forth.The embodiments, however, are not limited to implementation by thecomputing architecture 700.

As shown in FIG. 7, the computing architecture 700 comprises aprocessing unit 702, a system memory 704 and a system bus 706. Theprocessing unit 702 can be any of various commercially availableprocessors, including without limitation an AMD® Athlon®, Duron® andOpteron® processors; ARM® application, embedded and secure processors;IBM® and Motorola® DragonBall® and PowerPC® processors; IBM and Sony®Cell processors; Intel® Celeron®, Core (2) Duo®, Itanium®, Pentium®,Xeon®, and XScale® processors; and similar processors. Dualmicroprocessors, multi-core processors, and other multi-processorarchitectures may also be employed as the processing unit 702.

The system bus 706 provides an interface for system componentsincluding, but not limited to, the system memory 704 to the processingunit 702. The system bus 706 can be any of several types of busstructure that may further interconnect to a memory bus (with or withouta memory controller), a peripheral bus, and a local bus using any of avariety of commercially available bus architectures. Interface adaptersmay connect to the system bus 706 via a slot architecture. Example slotarchitectures may include without limitation Accelerated Graphics Port(AGP), Card Bus, (Extended) Industry Standard Architecture ((E)ISA),Micro Channel Architecture (MCA), NuBus, Peripheral ComponentInterconnect (Extended) (PCI(X)), PCI Express, Personal Computer MemoryCard International Association (PCMCIA), and the like.

The computing architecture 700 may comprise or implement variousarticles of manufacture. An article of manufacture may comprise acomputer-readable storage medium to store logic. Examples of acomputer-readable storage medium may include any tangible media capableof storing electronic data, including volatile memory or non-volatilememory, removable or non-removable memory, erasable or non-erasablememory, writeable or re-writeable memory, and so forth. Examples oflogic may include executable computer program instructions implementedusing any suitable type of code, such as source code, compiled code,interpreted code, executable code, static code, dynamic code,object-oriented code, visual code, and the like. Embodiments may also beat least partly implemented as instructions contained in or on anon-transitory computer-readable medium, which may be read and executedby one or more processors to enable performance of the operationsdescribed herein.

The system memory 704 may include various types of computer-readablestorage media in the form of one or more higher speed memory units, suchas read-only memory (ROM), random-access memory (RAM), dynamic RAM(DRAM), Double-Data-Rate DRAM (DDRAM), synchronous DRAM (SDRAM), staticRAM (SRAM), programmable ROM (PROM), erasable programmable ROM (EPROM),electrically erasable programmable ROM (EEPROM), flash memory, polymermemory such as ferroelectric polymer memory, ovonic memory, phase changeor ferroelectric memory, silicon-oxide-nitride-oxide-silicon (SONOS)memory, magnetic or optical cards, an array of devices such as RedundantArray of Independent Disks (RAID) drives, solid state memory devices(e.g., USB memory, solid state drives (SSD) and any other type ofstorage media suitable for storing information. In the illustratedembodiment shown in FIG. 7, the system memory 704 can includenon-volatile memory 708 and/or volatile memory 710. A basic input/outputsystem (BIOS) can be stored in the non-volatile memory 708.

The computing architecture 700 may include various types ofcomputer-readable storage media in the form of one or more lower speedmemory units, including an internal (or external) hard disk drive (HDD)712, a magnetic floppy disk drive (FDD) 714 to read from or write to aremovable magnetic disk 716, and an optical disk drive 718 to read fromor write to a removable optical disk 720 (e.g., a CD-ROM or DVD). TheHDD 712, FDD 714 and optical disk drive 720 can be connected to thesystem bus 706 by an HDD interface 722, an FDD interface 724 and anoptical drive interface 726, respectively. The HDD interface 722 forexternal drive implementations can include at least one or both ofUniversal Serial Bus (USB) and IEEE 694 interface technologies.

The drives and associated computer-readable media provide volatileand/or nonvolatile storage of data, data structures, computer-executableinstructions, and so forth. For example, a number of program modules canbe stored in the drives and memory units 708, 712, including anoperating system 728, one or more application programs 730, otherprogram modules 732, and program data 734. In one embodiment, the one ormore application programs 730, other program modules 732, and programdata 734 can include, for example, the various applications and/orcomponents of the messaging system 500.

A user can enter commands and information into the computer 701 throughone or more wire/wireless input devices, for example, a keyboard 736 anda pointing device, such as a mouse 738. Other input devices may includemicrophones, infra-red (IR) remote controls, radio-frequency (RF) remotecontrols, game pads, stylus pens, card readers, dongles, finger printreaders, gloves, graphics tablets, joysticks, keyboards, retina readers,touch screens (e.g., capacitive, resistive, etc.), trackballs,trackpads, sensors, styluses, and the like. These and other inputdevices are often connected to the processing unit 702 through an inputdevice interface 740 that is coupled to the system bus 706, but can beconnected by other interfaces such as a parallel port, IEEE 694 serialport, a game port, a USB port, an IR interface, and so forth.

A monitor 742 or other type of display device is also connected to thesystem bus 706 via an interface, such as a video adaptor 744. Themonitor 742 may be internal or external to the computer 701. In additionto the monitor 742, a computer typically includes other peripheraloutput devices, such as speakers, printers, and so forth.

The computer 701 may operate in a networked environment using logicalconnections via wire and/or wireless communications to one or moreremote computers, such as a remote computer 744. The remote computer 744can be a workstation, a server computer, a router, a personal computer,portable computer, microprocessor-based entertainment appliance, a peerdevice or other common network node, and typically includes many or allof the elements described relative to the computer 701, although, forpurposes of brevity, only a memory/storage device 746 is illustrated.The logical connections depicted include wire/wireless connectivity to alocal area network (LAN) 748 and/or larger networks, for example, a widearea network (WAN) 750. Such LAN and WAN networking environments arecommonplace in offices and companies, and facilitate enterprise-widecomputer networks, such as intranets, all of which may connect to aglobal communications network, for example, the Internet.

When used in a LAN networking environment, the computer 701 is connectedto the LAN 748 through a wire and/or wireless communication networkinterface or adaptor 752. The adaptor 752 can facilitate wire and/orwireless communications to the LAN 748, which may also include awireless access point disposed thereon for communicating with thewireless functionality of the adaptor 752.

When used in a WAN networking environment, the computer 701 can includea modem 754, or is connected to a communications server on the WAN 750,or has other means for establishing communications over the WAN 750,such as by way of the Internet. The modem 754, which can be internal orexternal and a wire and/or wireless device, connects to the system bus706 via the input device interface 740. In a networked environment,program modules depicted relative to the computer 701, or portionsthereof, can be stored in the remote memory/storage device 746. It willbe appreciated that the network connections shown are exemplary andother means of establishing a communications link between the computerscan be used.

The computer 701 is operable to communicate with wire and wirelessdevices or entities using the IEEE 802 family of standards, such aswireless devices operatively disposed in wireless communication (e.g.,IEEE 802.13 over-the-air modulation techniques). This includes at leastWi-Fi (or Wireless Fidelity), WiMax, and Bluetooth™ wirelesstechnologies, among others. Thus, the communication can be a predefinedstructure as with a conventional network or simply an ad hoccommunication between at least two devices. Wi-Fi networks use radiotechnologies called IEEE 802.13x (a, b, g, n, etc.) to provide secure,reliable, fast wireless connectivity. A Wi-Fi network can be used toconnect computers to each other, to the Internet, and to wire networks(which use IEEE 802.3-related media and functions).

FIG. 8 is a block diagram depicting an exemplary communicationsarchitecture 800 suitable for implementing various embodiments aspreviously described. The communications architecture 800 includesvarious common communications elements, such as a transmitter, receiver,transceiver, radio, network interface, baseband processor, antenna,amplifiers, filters, power supplies, and so forth. The embodiments,however, are not limited to implementation by the communicationsarchitecture 800.

As shown in FIG. 8, the communications architecture 800 includes one ormore clients 802 and servers 804. The clients 802 may implement theclient device 510. The servers 804 may implement the server device 526.The clients 802 and the servers 804 are operatively connected to one ormore respective client data stores 806 and server data stores 808 thatcan be employed to store information local to the respective clients 802and servers 804, such as cookies and/or associated contextualinformation.

The clients 802 and the servers 804 may communicate information betweeneach other using a communication framework 810. The communicationsframework 810 may implement any well-known communications techniques andprotocols. The communications framework 810 may be implemented as apacket-switched network (e.g., public networks such as the Internet,private networks such as an enterprise intranet, and so forth), acircuit-switched network (e.g., the public switched telephone network),or a combination of a packet-switched network and a circuit-switchednetwork (with suitable gateways and translators).

The communications framework 810 may implement various networkinterfaces arranged to accept, communicate, and connect to acommunications network. A network interface may be regarded as aspecialized form of an input output interface. Network interfaces mayemploy connection protocols including without limitation direct connect,Ethernet (e.g., thick, thin, twisted pair 10/100/1000 Base T, and thelike), token ring, wireless network interfaces, cellular networkinterfaces, IEEE 802.8a-x network interfaces, IEEE 802.16 networkinterfaces, IEEE 802.20 network interfaces, and the like. Further,multiple network interfaces may be used to engage with variouscommunications network types. For example, multiple network interfacesmay be employed to allow for the communication over broadcast,multicast, and unicast networks. Should processing requirements dictatea greater amount speed and capacity, distributed network controllerarchitectures may similarly be employed to pool, load balance, andotherwise increase the communicative bandwidth required by clients 802and the servers 804. A communications network may be any one and thecombination of wired and/or wireless networks including withoutlimitation a direct interconnection, a secured custom connection, aprivate network (e.g., an enterprise intranet), a public network (e.g.,the Internet), a Personal Area Network (PAN), a Local Area Network(LAN), a Metropolitan Area Network (MAN), an Operating Missions as Nodeson the Internet (OMNI), a Wide Area Network (WAN), a wireless network, acellular network, and other communications networks.

The components and features of the devices described above may beimplemented using any combination of discrete circuitry, applicationspecific integrated circuits (ASICs), logic gates and/or single chiparchitectures. Further, the features of the devices may be implementedusing microcontrollers, programmable logic arrays and/or microprocessorsor any combination of the foregoing where suitably appropriate. It isnoted that hardware, firmware and/or software elements may becollectively or individually referred to herein as “logic” or “circuit.”

It will be appreciated that the exemplary devices shown in the blockdiagrams described above may represent one functionally descriptiveexample of many potential implementations. Accordingly, division,omission or inclusion of block functions depicted in the accompanyingfigures does not infer that the hardware components, circuits, softwareand/or elements for implementing these functions would be necessarily bedivided, omitted, or included in embodiments.

At least one computer-readable storage medium may include instructionsthat, when executed, cause a system to perform any of thecomputer-implemented methods described herein.

Some embodiments may be described using the expression “one embodiment”or “an embodiment” along with their derivatives. These terms mean that aparticular feature, structure, or characteristic described in connectionwith the embodiment is included in at least one embodiment. Theappearances of the phrase “in one embodiment” in various places in thespecification are not necessarily all referring to the same embodiment.Moreover, unless otherwise noted the features described above arerecognized to be usable together in any combination. Thus, any featuresdiscussed separately may be employed in combination with each otherunless it is noted that the features are incompatible with each other.

With general reference to notations and nomenclature used herein, thedetailed descriptions herein may be presented in terms of programprocedures executed on a computer or network of computers. Theseprocedural descriptions and representations are used by those skilled inthe art to most effectively convey the substance of their work to othersskilled in the art.

A procedure is here, and generally, conceived to be a self-consistentsequence of operations leading to a desired result. These operations arethose requiring physical manipulations of physical quantities. Usually,though not necessarily, these quantities take the form of electrical,magnetic or optical signals capable of being stored, transferred,combined, compared, and otherwise manipulated. It proves convenient attimes, principally for reasons of common usage, to refer to thesesignals as bits, values, elements, symbols, characters, terms, numbers,or the like. It should be noted, however, that all of these and similarterms are to be associated with the appropriate physical quantities andare merely convenient labels applied to those quantities.

Further, the manipulations performed are often referred to in terms,such as adding or comparing, which are commonly associated with mentaloperations performed by a human operator. No such capability of a humanoperator is necessary, or desirable in most cases, in any of theoperations described herein, which form part of one or more embodiments.Rather, the operations are machine operations. Useful machines forperforming operations of various embodiments include general purposedigital computers or similar devices.

Some embodiments may be described using the expression “coupled” and“connected” along with their derivatives. These terms are notnecessarily intended as synonyms for each other. For example, someembodiments may be described using the terms “connected” and/or“coupled” to indicate that two or more elements are in direct physicalor electrical contact with each other. The term “coupled,” however, mayalso mean that two or more elements are not in direct contact with eachother, but yet still co-operate or interact with each other.

Various embodiments also relate to apparatus or systems for performingthese operations. This apparatus may be specially constructed for therequired purpose or it may comprise a general purpose computer asselectively activated or reconfigured by a computer program stored inthe computer. The procedures presented herein are not inherently relatedto a particular computer or other apparatus. Various general purposemachines may be used with programs written in accordance with theteachings herein, or it may prove convenient to construct morespecialized apparatus to perform the required method steps. The requiredstructure for a variety of these machines will appear from thedescription given.

It is emphasized that the Abstract of the Disclosure is provided toallow a reader to quickly ascertain the nature of the technicaldisclosure. It is submitted with the understanding that it will not beused to interpret or limit the scope or meaning of the claims. Inaddition, in the foregoing Detailed Description, it can be seen thatvarious features are grouped together in a single embodiment for thepurpose of streamlining the disclosure. This method of disclosure is notto be interpreted as reflecting an intention that the claimedembodiments require more features than are expressly recited in eachclaim. Rather, as the following claims reflect, inventive subject matterlies in less than all features of a single disclosed embodiment. Thusthe following claims are hereby incorporated into the DetailedDescription, with each claim standing on its own as a separateembodiment. In the appended claims, the terms “including” and “in which”are used as the plain-English equivalents of the respective terms“comprising” and “wherein,” respectively. Moreover, the terms “first,”“second,” “third,” and so forth, are used merely as labels, and are notintended to impose numerical requirements on their objects.

What has been described above includes examples of the disclosedarchitecture. It is, of course, not possible to describe everyconceivable combination of components and/or methodologies, but one ofordinary skill in the art may recognize that many further combinationsand permutations are possible. Accordingly, the novel architecture isintended to embrace all such alterations, modifications and variationsthat fall within the spirit and scope of the appended claims.

What is claimed is:
 1. A computer-readable medium storing instructionsthat, when executed by processing circuitry of a contactless card, causethe processing circuitry to: determine data to communicate to arecipient; access a shared secret stored in memory of the contactlesscard; combine the shared secret and the data; generate a firstdiversified session key having a first number of bits with a master key;apply, utilizing the first diversified session key, a messageauthentication code (MAC) algorithm to the shared secret and the data togenerate a MAC output; generate a second diversified session key havinga second number of bit with the master key; encrypt the MAC output withan encryption algorithm and the second diversified session key togenerate encrypted data; and transmit the encrypted data to therecipient.
 2. The medium of claim 1, wherein the at least a part of theMAC output is combined with a random element, and the random element istransmitted to the recipient with the encrypted data.
 3. The medium ofclaim 1, wherein the shared secret is a random number used to initializethe contactless card and is known to the recipient.
 4. The medium ofclaim 1, wherein the data is combined with the shared secret bymultiplying the shared secret with the data.
 5. The medium of claim 1,wherein the data is combined with the shared secret by concatenating thedata with at least a portion of the shared secret.
 6. The medium ofclaim 1, wherein the first diversified key and the second diversifiedkey are different.
 7. The medium of claim 1, wherein utilizing the firstdiversified key and the second diversified key satisfies a securityrequirement.
 8. The medium of claim 7, wherein a summation of the firstnumber of bits and the second number of bits meets or exceeds a numberof bits for the security requirement.
 9. A computer-implemented method,comprising: determining, by a contactless card, data to communicate to arecipient; accessing, by the contactless card and from memory a sharedsecret stored in memory of the contactless card; combining, by thecontactless card, the shared secret and the data; generating, by thecontactless card, a first diversified session key having a first numberof bits with a master key; applying, by the contactless card andutilizing the first diversified session key, a message authenticationcode (MAC) algorithm to the shared secret and the data to generate a MACoutput; generating, by the contactless card, a second diversifiedsession key having a second number of bit with the master key;encrypting, by the contactless card, the MAC output with an encryptionalgorithm and the second diversified session key to generate encrypteddata; and sending, by the contactless card via a transceiver, theencrypted data to the recipient.
 10. The computer-implemented method ofclaim 9, wherein the at least a part of the MAC output is combined witha random element, and the random element is transmitted to the recipientwith the encrypted data.
 11. The computer-implemented method of claim 9,wherein the shared secret is a random number used to initialize thecontactless card and is known to the recipient.
 12. Thecomputer-implemented method of claim 9, wherein the data is combinedwith the shared secret by multiplying the shared secret with the data.13. The computer-implemented method of claim 9, wherein the data iscombined with the shared secret by concatenating the data with at leasta portion of the shared secret.
 14. The computer-implemented method ofclaim 9, wherein the first diversified key and the second diversifiedkey are different.
 15. The computer-implemented method of claim 9,wherein utilizing the first diversified key and the second diversifiedkey satisfies a security requirement.
 16. The computer-implementedmethod of claim 15, wherein a summation of the first number of bits andthe second number of bits meets or exceeds a number of bits for thesecurity requirement.
 17. A contactless card, comprising: memoryconfigured to store instructions; processing circuitry coupled with thememory, the processing circuitry configured to process the instructions,that when executed, cause the processing circuitry to: determine data tocommunicate to a recipient; access a shared secret stored in memory ofthe contactless card; combine the shared secret and the data; generate afirst diversified session key having a first number of bits with amaster key; apply, utilizing the first diversified session key, amessage authentication code (MAC) algorithm to the shared secret and thedata to generate a MAC output; generate a second diversified session keyhaving a second number of bit with the master key; encrypt the MACoutput with an encryption algorithm and the second diversified sessionkey to generate encrypted data; and transmit the encrypted data to therecipient.
 18. The contactless card of claim 17, wherein the at least apart of the MAC output is combined with a random element, and the randomelement is transmitted to the recipient with the encrypted data.
 19. Thecontactless card of claim 17, wherein utilizing the first diversifiedkey and the second diversified key satisfies a security requirement. 20.The contactless card of claim 19, wherein a summation of the firstnumber of bits and the second number of bits meets or exceeds a numberof bits for the security requirement.